BCI NET

home *** CD-ROM | disk | FTP | other *** search

/ BCI NET / BCI NET Dec 94.iso / archives / telecomm / bbs / d342.lha / UTIL3.man < prev next >

Wrap

Text File | 1992-04-15 | 44.8 KB | 1,260 lines

C I T A D E L - 8 6 V3.40 UTILITIES MANUAL Copyright 1989 - 1991 by Hue, Jr. C-86 Test System Sysop 91Sep15 TABLE OF CONTENTS History . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 Clog.exe . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Clray.exe . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Recover1.exe . . . . . . . . . . . . . . . . . . . . . . . . 3 Expand.exe . . . . . . . . . . . . . . . . . . . . . . . . . 4 Recover2.exe . . . . . . . . . . . . . . . . . . . . . . . . 4 DataChng.exe . . . . . . . . . . . . . . . . . . . . . . . . 5 Logedit.exe . . . . . . . . . . . . . . . . . . . . . . . . . 5 Popular.exe . . . . . . . . . . . . . . . . . . . . . . . . . 6 Culldir.exe . . . . . . . . . . . . . . . . . . . . . . . . . 6 Nodelist.exe . . . . . . . . . . . . . . . . . . . . . . . . 7 MsgAdd.exe . . . . . . . . . . . . . . . . . . . . . . . . . 7 MsgOut.exe . . . . . . . . . . . . . . . . . . . . . . . . . 8 Clean.Exe . . . . . . . . . . . . . . . . . . . . . . . . . . 8 VirtAdmn.Exe . . . . . . . . . . . . . . . . . . . . . . . . 9 RoutMail.Exe . . . . . . . . . . . . . . . . . . . . . . . . 9 Screen.Exe . . . . . . . . . . . . . . . . . . . . . . . . . 16 Ease.Exe . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Aff.Exe . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Vexfind.exe . . . . . . . . . . . . . . . . . . . . . . . . . 18 -1- History The following is a chronological chart of the history of the updates of the C-86 utilities. 91Mar31 HAW MsgAdd and MsgOut updated for Virtual Rooms. 90May HAW Aff; update RoutMail with +domains. 89Jun22 HAW Ease. 89Apr17 HAW Version 2 of LogEdit. 89Feb26 HAW Major Release update(3.16): Clean, RoutMail, VirtAdmn, Screen. 88Dec19 HAW MsgAdd, MsgOut; general cleanup. 88Jan04 HAW Culldir, Nodelist, and Loadshar detailed. Lexpand deleted. 87Oct16 HAW V3 of Citadel-86 update. 86Apr08 HAW Version 2 of Popular detailed. 86Apr01 HAW Popular detailed. 85Aug25 HAW Ctdlchng expanded. 85Aug10 HAW Logedit detailed. 85May25 HAW Lexpand detailed. 85Apr25 HAW Reviewed for MS-DOS conversion. 85Feb18 HAW Recover2 detailed. 84Dec09 HAW Expand changed. 84Jun29 HAW Ctdlchng detailed. 84Jun28 HAW Expand detailed. 84Jun27 HAW Recover1 detailed. 84Jun26 HAW Clray detailed. 84Jun26 HAW Created. Clog detailed. Introduction Since the days of yore when we received Citadel from CUG (C User's Group), several utilities of interest have been added to the package to supplement the original two .com files that came with the package, to wit CITADEL.COM and CONFIGUR.COM. These come in two types: one, to provide information about what's going on inside this monster which, due to runtime space considerations, could not be gotten at; two, the ability to change certain parameters which were either impossible to change once a BBS was set up, or were, at the least, difficult to change. The descriptions (such as they are) follow herein! Clog.exe Clog provides access to the userlog for the Sysop. To use it, the file CTDLTABL.SYS (the one generated by CONFG and maintained by CTDL.EXE) must be on the default disk, and so must be CTDLLOG.SYS. There are two ways of using Clog. First, there is the simple call: D>CLOG This will print out on the console the list of users in the file as they appear in the file. The user of this program should be warned that Citadel does not put new users into the userlog in sequential order. Instead, they are hashed into the log. Usually, first user to log into the system ends up occupying the last position in the file! In general, users are sprinkled everywhere, so don't be alarmed if nothing shows up right away. Be patient. -2- In any case, the list is printed out as follows. First, the log position will be printed out, which will always be in sequential order. If nobody occupies that position, then Clog proceeds to the next log position. If somebody does occupy that position, then the name of that person (or alias) will be printed out, followed by his/her status as aide, expert/non-expert, screen width, and if they have net privileges the entry will be followed by a 'N'. The second way to use Clog is to give it arguments. There are two arguments currently available in the MS-DOS version. The first is the -P argument: D>CLOG -P This will cause the passwords to be listed along with the user's name. This is useful if somebody forgets their password. The second argument is a user's name. When a user's name appears on the command line, then data for that account only will be shown. You may use -P and a user's name on the same command line. If, for some reason, the sysop wants a list to be put out to a file, use the MS-DOS re-direction commands. If you want the list to be put out to the file LOG.LST, the type D>CLOG >LOG.LST Naturally, the -P argument may still be used when re-directing output. Clray.exe Clray.exe is another program used to view the userlog. As before, CTDLTABL.SYS must be on the default disk in the root directory, as must CTDLLOG.SYS. There are currently no arguments for Clray. Clray's purpose is to allow the sysop to see what order the users have been calling in, starting with the last caller. Along with the users name, his/her aide status, column width, and expert status will be printed, as in Clog. Simply call Clray to run it. Output redirection may be used as in CLOG. Recover1.exe Occasionally, a room may be killed by accident by an aide. Or worse, a Village Idiot will break an aide's password, and then kill rooms which the Sysop thinks has socially redeeming value. It is at this point that Recover1 may be of use. Recover1 may only be used if the following applies -- rooms have been killed, but no rooms have been created. If a room(s) has been created, it may have overwritten the old data. Rooms which weren't overwritten can still be saved of course. If new rooms have been created, Recover2.exe should be used. -3- To use Recover1, the system should be setup as normal. Simply call Recover1. It will read in CTDLTABL.SYS. Then it will start looking at the rooms as found in CTDLTABL.SYS. When it finds evidence that a room has been killed, it will printout on the screen the name of the room, and ask the Sysop if s/he wants Recover1 to try to save the room. If it receives an upper or lower case Y, then it will do so. Currently, there is no reason known why it shouldn't succeed. When finished it will announce so and replace CTDLTABL.SYS with the updated version, and then leave. However, hopefully you'll never need this program. Expand.exe Expand's purpose in life is to allow the sysop to expand the size of his/her message file (CTDLMSG.SYS). This makes it easy to move upwards as one gets rich running Citadel for cold, hard cash and acquires better and better equipment. Expand expects to the system to be in its normal setup. Simply call Expand without arguments. Once it has loaded CTDLTABL.SYS, it will display the current size of the message file, and then ask for the new size. Answer in Kbytes. Now Expand will do it's job. THIS IS A SLOW PROCESS. Be patient. The program will be printing some stuff out that might allow the sysop to figure out where the program is. Once the program is done, it will say so, and will also tell you that there is no reason to reconfigure. This is true. Recover2.exe Recover2.exe is to be used in the extreme emergency of either A) someone breaking an aide pwd and deleting rooms and then creating other rooms, thus negating the utility of Recover1.exe, or B) the loss or contamination of CTDLROOM.SYS. Use of Recover2.exe really should be avoided. The effects of Recover2.exe are: * All <Z>Forgotten room lists are totally screwed up; * Privacy status of rooms are lost and will have to be reset; * Directory status of rooms are also lost and will have to be reset; * Deleted messages will reappear in their rooms of origin; * And so will inserted messages. * Various other room privileges will be lost or screwed up. * Everything will end up on the base floor. Recover2.exe works by scanning the message file. Each message has associated with it its room of origin, so the program is fairly simple. However, it is also rather slow. The system should setup as normal. -4- DataChng.exe The purpose of the DataChng.exe utility is to give the sysop the ability to non-destructively several CTDLCNFG.SYS parameters. The relevant parameters are: #MAXROOMS #MSG-SLOTS #MAIL-SLOTS #LOGSIZE #SHARED-ROOMS #NET-ARCH-ROOMS ALWAYS MAKE BACKUPS BEFORE USING THIS UTILITY! DataChng is a very crude and simple menu-driven program which exits when an illegal selection is made from the menu. On valid selections, DataChng will ask for a new value, and then ATTEMPT to modify your installation for the new value. NOTE: As of this writing, the system attempts all changes IN MEMORY. If there is not enough RAM, then this utility fails. This should only happen for very large installations ("large", in this case, does not refer to the message base; see EXPAND.EXE for details on expanding your message base). If this happens to you, then you should either attempt to hack the source for this utility so that it uses temporary files (a tedious but simple procedure), or entice someone into doing it for you (ibid). With the exception of the LOGSIZE parameter, all of the parameters may either be shrunk or expanded. LOGSIZE can only (currently) be expanded. Make sure to update your CTDLCNFG.SYS after using DataChng.exe! However, you do NOT need to use CONFG.EXE after using DataChng.exe. Logedit.exe LOGEDIT provides the ability to edit the user log offline. LOGEDIT will act in one of two ways, depending on the machine your system is configured for. If the configuration is for a Zenith Z-100, LOGEDIT will be a simple, very crude question and answer routine. The system will ask for an account to kill, which you answer by NUMBER (use CLOG to find the numbers you need). If you confirm the kill, the account is nuked. If the configuration is for a PClone, LOGEDIT will be a visually oriented utility. The account names will be listed; you may select any by using the cursor keys. Touching the DEL key will cause the current account to be nuked. Touching the carriage return will allow you to view and edit the values of the account. Touching the ESC key will end LOGEDIT. The last action LOGEDIT performs is to digest the user log. Please do not interrupt it during this task. -5- Popular.exe The POPULAR utility is a statistics-gathering utility, and, as such, can be easily viewed as your basic feeping creaturism. However, for those of us who have somehow acquired that horrible taste for odd statistics about how people use Citadel, it does serve some purpose. POPULAR gathers statistics about the Public rooms on a system. These statistics consist of simply calculating how many people have forgotten each Public room on a system. Yes, a rather odd statistic to gather, but there it is. Once it has finished processing the data, it displays the results in tabular form, in (roughly) the following form: <room name> <# of people who have forgotten this room> <% of total users> To use this utility, simply make sure your data files are in their normal drives, and run this program. The output of this program may be redirected to a file via the MS-DOS ">" directive, although not all the output will end up in the output file. Unimportant output will continue to go to the screen; the important data will end up in the file you designated. There is one command line option available, "-M". If this option is on the command line to Popular, it will also scan the message file, counting the number of messages that originated in each room and performing AML calculations on a per room basis, and display those values for each public room in the same tabular format. The rooms are displayed in descending order of how many people have forgotten each room. Culldir.exe The Culldir utility is to be used in conjunction with active directory rooms. Let's face it: while the FILEDIR.TXT/.RE option is real handy for directory rooms, it's a real pain trying to keep FILEDIR.TXT culled of files that no longer exist in the directory. That's what Culldir is for. It will go through a FILEDIR.TXT and delete all entries in it for which files do not exist in the current directory. Usage is very simple. Place yourself in the DOS directory that has a FILEDIR.TXT with extra entries in it, and run Culldir. It expects all of the data that it will work on to be on the default drive, in the current directory. If it doesn't find a FILEDIR.TXT, it will abort operation. Culldir is unique amongst the utilities in that it doesn't need any of the normal Citadel-86 data files -- only a directory with FILEDIR.TXT in it. -6- Nodelist.exe Nodelist is intended to help you maintain, in some slight way, your netlist. There are two modes to Nodelist, with and without arguments. When you run Nodelist without arguments, its output to the screen will consist of a listing of shared rooms. Underneath each shared room will be a list of the systems that you are sharing the room with, terminated by a blank line. You may use DOS' redirection ability ('>') to place the output in a file. Using arguments with Nodelist will, of course, alter its behavior. There are three arguments currently supported. The first is "-n". This causes all the nodes on your nodelist that are not disabled to be listed. The second argument is "-nd", and causes all nodes on your nodelist, regardless of their status, to be listed. The third argument is "-s", which causes each system on your nodelist that you share rooms with to be listed, along with the rooms you share. MsgAdd.exe MsgAdd.exe is utility for use with programs which act as gateways between Citadel-compatible systems and other (foreign) networks. Its purpose is to allow the addition of messages to a Citadel-86 message base. The 'typical' system operator will rarely have a use for this utility. The command line format of MsgAdd is C>MsgAdd <node name> <file names> The first argument, node name, should be the name of a node on your nodelist, typically (although not always) a node which has been designated OtherNet. The purpose of specifying a node name is to allow correct routing address decisions to be made by MsgAdd, which will in turn allow Citadel-86 to route messages from the foreign network to other Citadel-86 systems. There should be at least one file name following the node name. Each file should contain at least one message from the foreign network in C86Net message format (see NETHACK3.MAN for the complete specification). Of all the fields that makes up a C86Net message, the following should be filled in by the gateway program for each message: Author Date Name of Origin System - need not be 'node name' in the command line Node ID of Origin System - a matter for some thought Room for message - a MUST Recipient iff msg is private mail Message Text Attempting to add messages to rooms which are not shared with 'node name' will result in warning messages, but the messages will be inserted. By formally sharing rooms with 'node name' you ensure that the companion utility to MsgAdd, MsgOut, will pick up messages for the foreign net and speed them on their way. -7- There is one weakness in MsgAdd: it does not do vortex processing on the messages from the foreign network. This is simply the result of a lazy programmer. However, when dealing with virtual rooms, the Msgout utility (detailed below) should always be run before the Msgadd utility due to the way Citadel-86 remembers which messages still need to be sent to other nodes. MsgOut.exe MsgOut is the reverse of the MsgAdd utility -- it will extract messages from a Citadel-86 installation and write them to a file in C86Net format, for later processing by a gateway program for insertion into a foreign network. The 'typical' system operator will have little to no use for this utility. Command line format for MsgOut is C>MsgOut <node name> <filename> 'node name' is the name of a node on your nodelist for which you wish to extract messages, while 'filename' is the file to place all such messages in, no matter what room they came from. So, the question becomes, "What messages are extracted?" The answer is conceptually simple: Think of 'node name', despite being a designation of a foreign (OtherNet) network, as just another C86Net system. MsgOut is then just like a normal network session. All messages which would have been sent to this system during a normal network session, both shared rooms and netMail, will be written to 'filename' in C86Net format. The gateway program is then expected to digest 'filename' and pass on those messages to the foreign network in the appropriate format. MsgOut will handle virtual rooms, but always make sure MsgOut is run before Msgadd; otherwise, MsgOut will not find and place in the file all outgoing messages meant for the foreign network. Clean.Exe The Clean utility is an anti-ruggie utility. Occasionally, a ruggie will gain access to your system and flood a favored room with messages of negative social value. The most frustrating fact of this behavior is the knowledge that the good messages which were scrolled out of the room are still in the message base, but no longer accessible. This utility will make them available. Simply run Clean from the command line. Clean will prompt for a room name, and then a list of names to 'clean' from the room (in case more than one ruggie has attacked). Once you have typed in all names you wish cleansed from the room, Clean will scan through your entire message base for messages belonging to the named room. Those messages written by users you designated will not be saved in the room any longer, while those by users you did not name will be saved, thus recovering 'scrolled' messages. Those messages cleansed will no longer be accessible (unless you run Clean again on the same room and forget to name those users!). Perhaps sometime in the future this utility will be modified to allow cleansing an entire roombase of a user. -8- VirtAdmn.Exe This utility is the Virtual Room Administrator for Citadel-86, and as such is of interest only to backbones with heavy traffic. The motivation and usefulness of VirtAdmn are explained in Section III.3.i of Network3.Man. VirtAdmn has two modes to it. The first mode, interactive, is accessed by simply typing 'VirtAdmn' at the DOS command line. It will place you in a primitive but adequate menu driven system which will let you add, delete, and modify virtual rooms from your system. The second mode is 'batch' mode. This mode is used to allow VirtAdmn to delete 'virtual' messages from your system which are no longer needed, that is, which have already been delivered to all eligible systems. We suggest this be run fairly often to keep your disks from running out of room, as some net rooms have fairly high traffic levels. Consider using an external event to run Batch mode, possibly as part of an automated backup procedure. Invocation of batch mode is by typing 'Virtadmn +batch' at the command line. There is one more option which may be used with VirtAdmn, in both the interactive and batch modes, and that is the 'log' option. When used, the results of the operation of VirtAdmn will be placed in your NETLOG.SYS file. Simply add '+log' to the command line if you wish this to occur. RoutMail.Exe This section of the Utilities manual documents the program RoutMail.Exe. RoutMail.Exe handles the administrative side of the C86Net RouteMail feature. This is divided into two sections. The first section is of interest to any sysop wishing to participate in C86Net RouteMail. The second section is of additional interest to System Operators of backbone systems which will be routing Mail for other systems. Please note that with the release of V3.32, which can support secondary node lists (see NETWORK3.MAN) that are updated automatically, most sysops' only use for RoutMail will be the +manual option. Even the major backbones (Domain Handlers) will have use, most of the time, only for the '+domains' option (see below), along maybe with '+kill'. GLOSSARY HUB: A "HUB" node is any node which is willing to accept mail from one node for delivery to another node. This may optionally not include nodes for which such traffic is very light and irregular, but will apply to heavily used backbones such as Utica College, Chaos II, AARDVARK!, KAOS, Test System, etc. PEON: A "PEON" node is a node which will carry very little or no netMail from one node to another, but is more likely to simply send and receive such netMail. Section 1: C86Net RouteMail for everyone. a) What is "RouteMail"? RouteMail is a feature of Citadel-86's C86Net which allows systems to send netMail to other systems without calling those systems directly. -9- b) How does it work internally? Briefly, any system will know how to send netMail to any system on its nodelist. A), it'll call it directly, or B) it will call some other node and ask it to pass the netMail on to the target system. In the case of B), it's not impossible, and in fact fairly normal, for this intermediate system to call yet another system in order to pass the netMail onwards, and this can continue, step by step, until it reaches its destination. Three well-known systems of the net, for instance, are Chaos II in Edmonton, Utica College (UCC) in Utica, NY, and Test System in the Twin Cities of Minnesota. Test System talks to the other two on a nightly basis, but UCC and Chaos II rarely talk to each other. Suppose Chaos II wishes to send netMail to UCC. During its nightly talk to Test System, it would ask Test System to take this netMail and send it to UCC. The next time Test System talks to UCC, it would ask it to accept the Mail. If the target was not UCC, but some system "beyond" UCC, it would in turn try to pass it on to that system, given that Test System knew that in order to get to this system beyond UCC, it should go via UCC. And etc. c) So why RoutMail.Exe? To keep the main executables smaller. Since you can run RoutMail as a local door, and possibly as a remote door, this should not cause problems or inconvenience. RUNNING ROUTMAIL RoutMail can be run in one of two modes. The first mode is called 'automatic' mode, and the second mode is called 'manual'. The purpose of automatic mode is to allow the sysop to update the current netMail routes of C86Net on an automatic basis. When RoutMail is run in this mode it will read a textfile describing the current C86Net configuration and update your nodelist with it, subject to some control on your part. Updating may include rerouting mail when a path to a node becomes invalid and is replaced with another. The generic command line of RoutMail in automatic mode is this: C>RoutMail [options] <mapfile> That is, the program followed by zero or more 'options' selections followed by the name of the map file to be digested by RoutMail. Your first question is probably, "What's this about a map??" The map, as noted, is a textfile describing the current C86Net. The precise format of the map is described in Section 2 (Advanced) of this file, and should not be of concern to you unless you are a backbone likely to be involved in the construction of the map, or enjoy abstruse details. A current map should be available at all times from your local backbone (if you are not a backbone), or from one of the major backbones of the net (if you are a backbone and want a more uptodate map), possibly Arcadia in Michigan. So now you'll want to know what these 'options' will do for you. Options supported at the moment are -10- "+add": allows RoutMail to add all unknown nodes found in the map to your nodelist. Such nodes will always be added as 1200 baud, non-local nodes attached to net #15, under the assumption that most sysops will not be using that net. If you don't use this option, then nodes you are not aware of on the net will not be added to your nodelist. This will let you keep your nodelist small. In fact, there's little use (with the release of V3.32) for this option; most routing responsibilities will be taken over by the domain handling options (see below). "+kill": allows RoutMail to delete nodes from your nodelist which have been designated in the map as "dead" nodes, that is, nodes which are permanently off the network. If you don't use this option, any node designated as dead will not be affected on your nodelist. "+domains": this option lets the sysop add in to his primary node list only those systems which are listed as Domain Handlers in his CtdlDmhd.Sys file AND those systems via which, according to the routmail map which was also present on the command line, you would use to get to those nodes. This option is very useful to those systems which are already Domain Handlers (since they are also usually backbones on the network, and therefore need to know how to get to those other domain handlers). We recommend Domain Handler sysops run RoutMail with the +domains option and the latest RoutMail map whenever they receive a new CtdlDmhd.Sys from their distribution point. The second RoutMail mode is 'manual'. Manual mode allows you to carry out RoutMail and other network administration (as a convenience) on nodes. The command line for using RoutMail.Exe in manual mode is C>RoutMail +manual Your options vis a vis RoutMail and nodes are as follows: o Accepting RouteMail from any given node (allows you to bar 'rogue' Citadels from abusing your system) o Accepting RouteMail for any given node (allows you to not accept netMail for any given system) Precise procedures for using RoutMail in manual mode should be self-explanatory in the program prompts. Miscellanea about C86Net RouteMail itself ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is not compatible with STadel mail routing. However, this only applies to intermediate backbones; a target of a mail routing may be any node which supports C86Net normal mail - the Citadel-86 doing the routing will convert the mail to normal mail for the final relay to the target node. See NETWORK3.MAN on being a STadel gateway. Section 2: Advanced - Map file structure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This section describes the structure of the map file. Since the map is really all about systems, first we should specify how to put a system on the map. The jargon we'll use is 'system identifier', and the format is this: <system node ID>:<system name> [@<baud>] -11- An example would be US 612 470 9635 : Test System and US 612 470 9635 : Test System @2400 would also be valid. Note that while the nodeId given must be the system's node id, the node name doesn't necessarily have to match what that system uses for a nodename. This alleviates problems with ridiculous names (such as TTWOL's insistence on including its phone number in its nodename). When entering data into a mapfile, only data starting at the left most column is significant. Any line starting with one or more blanks is considered a comment, not of use to RoutMail. The general structure of the map is this PEONS <description of all hub->peons relationships> HUBS <description of all hub->hubs relationships> CHANGES <description of all changes to individual nodes> DEAD <listing of systems that were on the net which are now off> COMMENTARY <talk about the netmap, if any> The PEONS / HUBS / DEAD /etc. titles allow RoutMail to identify what the data is all about. We'll now go over the format of data for each section in detail. PEONS section This section identifies which "hubs" talk to which "peons" directly. As noted in the glossary, a "hub" node is a node which is willing to carry a lot of netMail from one node to another node, while "peons" are nodes which do not act, usually, as intermediaries between different nodes. -12- This section's format is a series of records, each record separated from the next by a blank line. Each record is structured like this: <hub identifier> <peon identifier> <peon identifier> <peon identifier> ... Each record contains one hub node, the first in the list, and all of the peon nodes which it will service. No hub nodes should appear as peons in these lists! For instance, one possible record would be CA CA 403 433 2454 : Chaos II CA CA 403 455 1701 : Quincunx CA CA 403 426 1401 : Rock which would detail all the peons Chaos II services. However, it would be incorrect to add Test System to the bottom of that particular list, because Test System will be serving as a hub. The relationship between Test System and Chaos II is described in the HUBS section, since they are both hubs. However, Test System would appear as the first member of another list in the PEONS section, describing itself as a hub for systems in the Twin Cities area. While no hub may appear in any of the lists as anything other than a hub, and then only once, a peon may appear in more than one hub's listing. This is due to the reality that more than one hub may exist in an area, such as the UCC/KAOS tandem. They don't overlap in their coverage, and so provide the only (current) paths to certain nodes. Note that while a hub must be able to carry C86Net route mail in order to be a hub, a Peon does not have to be similarly capable in order to be a Peon, thus allowing the attachment of STadels, C-68Ks, and other such normal Mail> capable systems to the netmap. While such systems are incapable of sending routed mail to other nodes, they may receive it. HUBS section This section serves to detail the hub configuration. The format is, once again, a series of records, each a list of system identifiers separated by blank lines. In this case, each record begins with a hub identifier, and is followed by one or more hub identifiers. The record serves as a definition of all hubs which the first hub communicates directly with. For instance, the listing for Chaos II would be CA CA 403 433 2454 : Chaos II US 612 470 9635 : Test System [any other hubs Chaos II communicates directly with] -13- Each hub in the C86Net should appear as a 'first' node once, and only once, listing each hub it communicates directly with. The implication is a high level of redundancy occurs. To complete our above example, it would be necessary that somewhere in the HUBS section an entry of the form US 612 470 9635 : Test System CA CA 403 433 2454 : Chaos II [any other hubs Test System communicates directly with] also appear. While the level of redundancy could undoubtedly be reduced ... it ain't for the first version of RoutMail. Sorry. CHANGES section This section allows automatic changes of the nodelist by listing all nodes which have changed IDs or (more rarely) names. The format in this section differs from all others. <old id> : <new id> : <name> [@baud] is used for each node which has changed. DEAD section The format of the DEAD section of nodes is simply a list of system identifiers. COMMENTARY section This section is functionally useless to RoutMail, and is ignored. It can be used as a way to distribute news, instructions, or whatever strikes the fancy of the mapmaker. MAP EXAMPLE The following is an example, based on our current situation, of a possible net map. Note that it's incomplete, since I don't know the situation of even the Twin Cities in complete detail, much less anywhere else. (* START OF EXAMPLE *) This file contains an example description of a C86Net topology similar to an actual situation, involving Edmonton, Alberta, the Twin Cities of Minnesota, Kalamazoo, Michgan, and Utica, NY. PEONS This section covers Utica, NY. Note that Jersey Devil, while a backbone for the shared rooms, is not route mail compatible and is thus a peon, while KAOS, much closer to UCC, is a hub itself for THE_LAND, an STadel, and thus not on UCC's peon list. Notice that since Swinger's is in the area covered by both KAOS and UCC, it appears in both their lists. US 315 792 3187 : Utica College US 315 735-2058 : Swinger's Den US 609 893 2152 : Jersey Devil -14- The land, being an STadel, is listed as a PEON, despite it being a main backbone for the ST side of C86Net. US 315 735 0545 : KAOS US 513 254 6811 : THE_LAND US 315 735-2058 : Swinger's Den This section covers Kalamazoo, Michigan. US 616 343 4136: Arcadia US 616 349 5887:The Beach US 616 381 3646:Secret Citadel This section is for the Twin Cities. US 612 470 9635 : Test System US 612 429 5001 : Backfence US (612) 431-4807 : Lumber Yard US 612-938-8580 : New Eden US 6124311107 : SuperComp III This section is for Edmonton. CA 403 433 2454 : Chaos II CA 403 455 1701 : QuinCunx HUBS Now for the hub descriptions. US 315 792 3187 : Utica College US 315 735 0545 : KAOS US 612 470 9635 : Test System US 315 735 0545 : KAOS US 315 792 3187 : Utica College US 612 470 9635 : Test System US 616 343 4136: Arcadia CA 403 433 2454 : Chaos II US 616 343 4136: Arcadia US 612 470 9635 : Test System CA 403 433 2454 : Chaos II US 612 470 9635 : Test System DEAD For completeness, we add one node in here, a node that recently went away in the Twin Cities. Note we skipped right over the CHANGES section. US 612 425 0554 : Ivory Tower COMMENTARY And now for the news.... (* END OF EXAMPLE *) -15- Screen.Exe Screen is a utility which allows easy modification of Citadel-86 sysConsole colors. Usage is simple, just type 'SCREEN'. You will then be allowed to select colors for both the foreground and background as you wish. Once you are satisfied with your selection, ESC will terminate the program. If you ran Screen in your installation's main directory, Screen will modify your CTDLTABL.SYS so that when you bring your system back up the colors will be as you selected. However, it will not modify your CTDLCNFG.SYS file for you. To help you do that, though, it will generate a file named COLORS which will list your selections. The reason you want to modify your CTDLCNFG.SYS is in case you have a crash or something which forces you to reconfigure. Screen will run equally well without a Citadel-86 installation, too. It simply will not modify anything but the COLORS file it generates. Ease.Exe Ease is the Citadel-86 installation and modification utility for the PC version of Citadel-86. It has two tasks, already implied: installation, and modification (editing) your system. In order to run effectively, Ease requires the files Ease.Hlp (which should always accompany Ease.Lzh), Ease2.Hlp, Modems, and access to Citadel-86's CONFG.EXE program. Ease's abilities as an installation program should allow the creation of a minimal, non-netting system by both the novice and experienced sysops, including the creation of a useable CTDLCNFG.SYS. Ease's abilities as the Citadel-86 modification program are extensive. They include o Enabling netting o Editing all policy options o Editing all file locations o Modifying file sizes o Video modifications o #event editing o #door editing o etc The abilities of the Citadel-86 utilities DataChng, Expand, and Screen are completely contained in Ease, and Ease becomes the primary Citadel-86 utility as of its release. Aff.Exe Aff, which stands for Automatic File Forwarding, is a Citadel-86 utility designed to simplify the job of automatically forwarding files from one system to another with only some initial sysop assistance. -16- The basic idea is there are certain files, updated from time to time, which should be sent to some set of systems after each update. (If this doesn't seem likely to you, then you probably have little use for this utility.) By using the Aff utility in combination with the Citadel-86 #event to bring your system down periodically to run Aff, you can automate the process of sending said files to other systems when they are updated. Enough of the arm-waving. In order for this to work, you have to tell Aff what you want sent, and where. You do this via a file you construct named CTDLAFF.SYS, which will be located in your #NETAREA directory. The structure of this file is: <filename> <system name> : 0 <system name> : 0 <system name> : 0 ... <blank line> <filename> <system name> : 0 <system name> : 0 <system name> : 0 The first line is the name of the file which will need to be sent each time it's updated. There is one trick to this "filename" -- while you create the file in #NETAREA, you run the Aff utility from the same place you run Ctdl, and therefore Aff will look at the filename from the perspective of the normal Citadel directory, not #NETAREA. So, if you use "relative" file names (like "..\hello.zip", etc), you'll have to be careful. If you want to be smart, just use absolute file paths (like "C:\PRODUCT\STUFF.ZIP"). All of the following lines up to the first blank line are the names of systems the file should be sent to. Notice the format -- it's "<system name> : 0". The reason for the ": 0" is that Citadel-86 will actually use CtdlAff.Sys to remember the last time it sent the file on to each system. As the days pass, the "0" you should write in there will change to other numbers. They represent the date stamp of the file last time you checked and sent it. Don't mess with those numbers unless you know what you're doing (it's usually not necessary, anyways). You can update CtdlAff.Sys anytime you like, deleting systems, adding systems, adding whole new file forwarding specs. However, the Aff utility itself cannot be run from within Citadel-86; the system must be down. For that reason, and if you don't already, you may want to consider putting together a #event of type external which will cause Aff to be run on an appropriate basis. See INSTALL3.MAN for more information. -17- VEXFIND.EXE Vortex handling in Citadel-86 (that is, the detection of loops in the network) is activated by placing +vortex on the command line of CTDL. The VEXFIND utility allows the display of information concerning the current vortex records. Vexfind may be used in one of two modes. First, just the name may be typed at the command line: C>VEXFIND This will result in all of the current names known to the vortex handler to be printed to the console. The second mode is to place a system name on the command line: C>VEXFIND "C-86 Test System" This allows the discovery of the index value associated with the named system. This can be used in turn to delete corrupted vortex records. The vortex records are the files named *.VEX in the #NETAREA directory. Once the index is found, simply delete "<index>.vex". And, unlike most other Citadel-86 utilities, this utility can be run while in #NETAREA or from your standard Citadel directory, because it doesn't need CtdlTabl.Sys if the vortex files (VORTEX.SYS) are in the current directory. -18-